Fix crash in path completions for URLs with a query or fragment - #65342

Part of #65068 (partially: the textDocument/completion panic "path must not contain a URL query or fragment" via getCompletionEntriesForRelativeModules -> getCompletionEntriesForDirectoryFragment, comment 1)

Analysis

String-literal path completions in a module specifier treat the specifier as "relative" when it starts with .//../, or (with no paths) when it is a rooted disk path or a URL (tspath.IsUrl, i.e. anything containing ://). getCompletionEntriesForDirectoryFragment then strips the basename and resolves the remaining directory portion against the script directory with RootedDirectoryPath.ResolveDirectory.

If that directory portion is URL-rooted and contains a ? or #, ResolveDirectory -> ToRootedPath hits the (intentional) assertion that rooted paths never carry a URL query or fragment:

declare function require(id: string): any;
require("https://example.com/a?b/c|");            // directory "https://example.com/a?b/"
require("http://localhost/#/routes/|");            // directory "http://localhost/#/routes/"
require("./foo https://example.com/?x/y|");        // "://" anywhere makes the whole string URL-rooted

(import/import() with such specifiers hit a separate module-resolution panic first, which is handled elsewhere; require in a .ts file isn't resolved, so it isolates the completion crash.) The same assertion is reachable when the script directory itself is URL-rooted and a relative fragment contains ?/#.

Before paths were strongly typed, this code used tspath.ResolvePath + DirectoryExists, which simply found no such directory. Strada (src/services/stringCompletions.ts) does the same: resolvePath(scriptDirectory, fragment) followed by tryDirectoryExists, which yields no completions for these inputs.

Fix

Add RootedDirectoryPath.TryResolveDirectory, which mirrors ResolveDirectory but returns false (instead of panicking) exactly when the path would resolve to a URL with a query or fragment. getCompletionEntriesForDirectoryFragment uses it and returns no path completions in that case, matching Strada. The tspath assertions are unchanged.

Because the fix is inside getCompletionEntriesForDirectoryFragment, it should also cover the sibling crash in #65068 where getCompletionEntriesForNonRelativeModules calls getCompletionEntriesForDirectoryFragment (comment 3), though that path isn't separately tested here.

Alternatives considered:

• Checking strings.ContainsAny(fragment, "?#") in the language service: this would also wrongly drop completions for legitimate on-disk directories whose names contain ?/# on non-URL paths, and would need to duplicate tspath's URL-root detection.
• Weakening the tspath assertion: rejected; rooted paths should never contain a URL query/fragment.

Tests: new fourslash test completionForStringLiteralUrlQueryOrFragmentNoCrash (panicked before the fix with the exact message from the issue), plus a small unit test for TryResolveDirectory.

Copilot Checklist

I successfully ran the applicable command at the end of my session, and it completed without error:

• npx hereby validate
• npx hereby validate --api (for TypeScript API changes)